마이크로 서비스 아키텍처(MSA)

근래의 웹 기반 분산 시스템의 디자인에 많이 반영되고 있는 아키텍처 스타일
대용량 웹 서비스가 많아짐에 따라 정의된 아키텍처이며, 그 근간은 SOA(Service Oriented Architecture)에 두고 있다.

SOA가 엔터프라이즈 시스템을 중심으로 고안된 아키텍처라면, MSA는 SOA에 근간을 두고 대용량 웹 서비스 개발에 맞는 구조로 사상이 경량화되고 대규모 개발 조직 구조에 맞도록 변형되었다.

특징

  1. MSA에서는 각 컴포넌트를 서비스라는 개념으로 정의한다. 서비스는 상호 컴포넌트 간의 의존성 없이 개발, 배포된다. 애플리케이션 로직을 분리해서 여러 개의 애플리케이션으로 나눠 서비스별로 톰캣을 분산배치한다

  2. 중앙 집중화된 하나의 데이터베이스를 사용하는 것이 아니라 서비스별로 별도의 데이터베이스를 사용한다. 이는 다른 컴포넌트에 대한 의존성이 없다는 장점이 있으나, 다른 컴포넌트의 데이터를 API 통신을 통해서만 가져올 수 있기 때문에 성능상 문제가 있을 수 있고, 이기종 데이터베이스 간의 트랜잭션을 묶을 수 없다.

  3. API Gateway 컴포넌트를 둔다.

  4. 각 서비스가 물리적으로 완벽하게 분리되기 때문에, 유연한 배포가 가능하다

  5. 부하를 많이 받는 서비스 컴포넌트만 확장할 수 있기 때문에 유연한 확장이 가능하다

문제점

성능 문제

서비스 간 API 통신을 이용하기 때문에 값을 JSON, XML에서 데이터 모델(ex. 자바 객체)로 변환하는 마샬링 오버헤드가 발생하고, 호출을 위해 이 메시지들이 네트워크를 통해서 전송하기 때문에 시간이 추가로 소요된다

메모리 문제

각 서비스를 독립된 서버에 분할 배치하므로, 중복되는 모듈에 대해 메모리 사용량이 늘어난다. 각각의 톰캣 인스턴스를 운용하고 스프링 프레임워크와 같은 공통 라이브러리가 필요하므로 서비스의 수만큼 중복된 양의 메모리가 필요하다

그러나 현대 인프라 환경에서는 컴퓨팅 파워나 네트워크 성능이 좋기 때문에 성능과 메모리는 문제가 되진 않는다

어려운 테스팅, 운영
  1. 특정 사용자 시나리오나 기능 테스트 -> 여러 서비스에 걸친다. 그래서 테스트 복잡도가 올라간다.
  2. 운영할 시스템의 개수가 많고 서비스별로 다른 기술을 사용한다면 필요한 기술 수도 늘어난다
서비스 간 트랜잭션 처리

모노리틱 아키텍처(Monolithic Architecture)에서는 트랜잭션이 문제가 있으면 쉽게 데이터베이스의 기능을 이용해서 롤백할 수 있었다. 그런데 API 기반의 여러 서비스를 하나의 트랜잭션으로 묶는 것이 불가능하므로 MSA에선 이렇게 할 수가 없다.

이를 위한 해결 방법은

  1. 금융, 제조처럼 트랜잭션 보장이 중요하다면 MSA 를 쓰지 않는 것

  2. 트랜잭션 실패 시 이를 애플리케이션으로 처리해주는 보상 트랜잭션(Compensation Transaction)으로 에러 처리 로직을 구현하는 것

  3. 트랜잭션을 묶어야 하는 두 개의 시스템을 네이티브 프로토콜을 이용해서 구현하고 API로 노출하는 방식인 복합 서비스(COmposite Service)를 만들어서 활용하는 것이 있다